前面很深入的帶大家理解 kube-schduler，現在針對實務上可以用到的知識加以說明，就是用 Filter 以及 Score 去理解排程的相關設定。

我們在第 13 天的文章提到一個複雜的排程情境，接下來要用排程相關的設定，並用 Filter 以及 Score 的角度去分析這些設定不一樣的地方。

如果你的資料庫，以 AWS RDS 為例，放在 A-zone，所以你希望 backend 靠近 A-zone，但是 你的 AWS RDS 有啟動 Multiple-AZ 的功能，當 A-zone 出現問題的時候會 Failover 到 B-zone，但是如果你用 NodeSelector 要求 Pod 排程到 A-zone Node，這時候你的 Pod 不會跟者 failover 到 zone-b，資料庫 failover 過去但是 backend 沒有 failover 過去，造成了 P0 事件，我們要怎麼避免？

我們可以用 nodeAffinity 讓 backend 優先排程 Zone-A，再來是 Zone-B

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 6
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - A-zone  # 優先在 A-zone 調度
          - weight: 50
            preference:
              matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - B-zone  # A-Zone 沒有節點就在 B-zone 調度

affinity and anti-affinity

接下來我們來比較 preferredDuringSchedulingIgnoredDuringExecution 以及 requiredDuringSchedulingIgnoredDuringExecution

這兩個名稱很像，但是在 requiredDuringSchedulingIgnoredDuringExecution 是在 filter 的階段作用，所以只有條件而沒有 weight 可以設定，但是 preferredDuringSchedulingIgnoredDuringExecution 就可以設定 weight

我們除了可以用 Filter 以及 Score 去分析 affinity 的設定之外，也可以用來分析 topologySpreadConstraints

topologySpreadConstraints

topologySpreadConstraints 常用於均勻排程 Pod 的設定，MaxSkew 設定最多可以容忍多少歪斜，而其中有個重要參數會完全改變歪斜發生後的排程行為，就是 whenUnsatisfiable。

當你把 whenUnsatisfiable: DoNotSchedule → 作用於 Filter
whenUnsatisfiable: ScheduleAnyway → 作用於 Score

接下來要講到 kube-scheduler 的重要部分啦！我會介紹一些實務上會用到工具以及 Pattern，期待大家到時候會喜歡。